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Abstract 

Defence  Research  and  Development  Canada  (DRDC)  - 
Valcartier,  with  the  support  of  the  CRAC  Laboratory  at 
Ecole  Polytechnique  de  Montreal,  carried  out  an  ambitious 
R&D  project  aiming  at  developing  a  tool  called  SoCLe 
which  integrates  the  design  of  software  applications  with 
their  security.  Integrating  the  design  of  software  applica¬ 
tions  and  security  into  a  unique  tool  is  not  only  particu¬ 
larly  innovative  but  also  crucial  to  ensure  the  quality  and 
security  of  critical  command  and  control  information  sys¬ 
tems.  Moreover,  as  it  is  50  to  100  times  more  expensive  to 
correct  a  software  error  once  the  design  phase  is  finished, 
detecting  and  correcting  errors  at  design-time  saves  time 
and  money.  This  paper  presents  the  SoCLe  project’s  major 
achievements  along  with  a  simplified  case  study  on  Caveats, 
as  an  illustrative  example  of  a  possible  military  application 
for  this  new  technology. 


1.  Introduction 

It  is  now  generally  recognized  that  the  design  phase  is 
crucial  to  the  development  of  high-quality  software.  Nowa¬ 
days,  software  is  omnipresent  and  its  faults  can  involve 
enormous  social  and  economic  repercussions.  Sad  exam¬ 
ples  abound:  the  Therac-25  radiotherapy  machine  (3  dead 
and  3  severely  wounded  persons),  the  ARIANE  5  rocket 

*The  Secure  OCL  expressions  (SoCLe)  project  was  sponsored  by 
Defence  Research  and  Development  Canada  (DRDC)  (Government  of 
Canada). 


(approximately  500  million  US  dollars  loss),  the  breakdown 
of  AT&T  network  (approximately  60  million  US  dollars 
loss),  etc.1  However,  programs’  behavior  is  generally  only 
validated  after  their  partial  or  complete  implementation,  us¬ 
ing  various  testing  techniques.  Moreover,  it  is  estimated  that 
correcting  a  software  error  after  its  implementation  is  50  to 
100  times  more  expensive  than  at  design-time  [2],  Thus, 
there  is  a  real  need  for  design-time  validation  techniques. 

With  this  objective  in  mind.  Defence  Research  and  De¬ 
velopment  Canada  (DRDC)  -  Valcartier  initiated  a  project 
to  develop  a  tool  that  allows  the  integration  of  security 
within  the  design  of  software  applications.  The  idea  is  an 
innovative  exploitation  of  constraints  in  Unified  Modeling 
Language  (UML)  diagrams.  These  security  constraints  are 
expressed  in  the  Object  Constraint  Language  (OCL),  hence 
the  name  Secure  OCL  expressions  (SoCLe).  The  UML  nota¬ 
tion  is  currently  the  de  facto  industrial  standard  for  the  de¬ 
sign  of  object-oriented,  modern  software.  Indeed,  it  is  used 
to  support  software  engineering  best  practices.  With  UML, 
it  is  possible  to  specify  the  structural  and  behavioral  aspects 
of  software  using  standardized  diagrams.  OCL  is  integrated 
into  the  UML  standard  and  expresses  class  invariants  and 
pre/post-conditions  on  operations.  These  constraints  spec¬ 
ify  and  clarify  the  meaning  of  UML  diagrams  by  precisely 
describing  the  correct  model  behavior. 

The  SOCLe  project  is  carried  out  by  a  team  of  student 
members  of  the  Conception  et  Realisation  des  Applications 
Complexes  (CRAC)  Laboratory  at  Ecole  Polytechnique  de 
Montreal ,  and  is  directed  by  professor  John  Mullins.  It 
tackles  the  important  problem  of  design-time  validation.  In 

1  According  to  wikipedia.org  and  cnn.com. 
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the  first  research  phase,  the  SoCLe  team  compiled  an  ex¬ 
haustive  state-of-the-art  study  in  order  to  judiciously  choose 
technologies  to  be  used  throughout  the  project.  UML  was 
essentially  selected  because  of  its  popularity  in  the  indus¬ 
try.  OCL  is  interesting  for  several  reasons:  it  is  integrated 
into  the  UML  standard,  it  is  easy  to  use,  and,  especially,  it 
is  possible  to  give  it  a  precise  and  unambiguous  meaning 
and  to  integrate  it  into  rigorous  verification  techniques.  Re¬ 
search  efforts  continued  thereafter  with  the  formal  design 
necessary  for  the  implementation  of  the  SoCLe  tool.  This 
implementation  phase  initially  targeted  the  development  of 
an  automatic  verification  engine,  and  then  the  design  of  a 
graphical  user  interface  for  this  engine.  Considerable  ef¬ 
forts  were  also  invested  in  order  to  improve  the  engine’s 
performance,  which  is  now  adequate. 

The  rest  of  this  paper  is  structured  as  follows.  Section 
2  discusses  similar  tools  found  in  the  literature.  Section  3 
presents  the  general  architecture  of  the  SoCLe  tool.  Section 
4  details  the  simplified  case  study  used  throughout  this  pa¬ 
per:  a  caveat-separation  system.  Sections  5,  6,  and  7  sketch 
the  utilization  of  the  tool  using  this  case  study.  Finally,  Sec¬ 
tion  8  presents  ongoing  improvements  to  the  tool  and  con¬ 
clusions.  Note  that  some  familiarity  with  UML  and  OCL  is 
assumed.  The  reader  is  referred  to  [10]  for  an  introduction 
to  UML.  Details  about  OCL  can  be  found  in  [9]. 

2.  Related  Work 

Few  research  tools  are  currently  available  for  static 
and/or  dynamic  validation  of  UML  diagrams.  Lilius  and 
Paltor  [8]  propose  vUML,  a  tool  that  translates  UML  state- 
chart  diagrams  into  Promela,  the  modeling  language  of  the 
SPIN  model-checker.  Constraints  are  expressed  through 
Linear  Temporal  Logic  (LTL)  and  are  transmitted  to  SPIN. 
Similarly,  Latella  et  al.  [7]  give  a  provably-correct  transla¬ 
tion  from  a  subset  of  UML  statechart  diagrams  into  Promela. 
None  of  these  approaches,  however,  have  taken  OCL  into 
account. 

The  toolset  proposed  by  Shen  et  al.  [11]  offers  static 
and  dynamic  validation.  Static  checks  include:  syntactic 
correctness  according  to  well-formedness  constraints  of  the 
UML  meta-model,  coherence  of  an  object  diagram  with  re¬ 
spect  to  a  class  diagram,  and  validation  of  OCL  constraints 
on  an  object  diagram.  The  dynamic  checks  consist  of  the 
verification  of  statechart  diagrams  using  the  SMV  model- 
checker.  However,  OCL  constraints  are  not  considered  by 
this  model-checker  either.  Therefore,  they  are  not  supported 
as  a  dynamic  constraint  specification  language. 

Extensions  for  OCL  constraints  are  suggested  by  Diste- 
fano  et  al.  [5],  using  Computational  Tree  Logic  (CTL),  and 
Bradfield  et  al.  [3],  using  propositional  //-calculus.  The 
general  idea  is  to  replace  the  atomic  properties  of  these  tem¬ 
poral  logics  by  standard  OCL  constraints.  Note,  however. 


that  neither  of  these  frameworks  support  UML  as  a  design 
notation. 

3.  SoCLe  Architecture 

SoCLe  is  divided  into  three  main  modules: 

1.  a  UML  compiler, 

2.  a  specialized  Abstract  State  Machine  (ASM)  interpreter 
[1],  and 

3.  a  model-checker  (Figure  l).2 

The  tool  works  with  UML  diagrams  expressed  in  the 
XML  Metadata  Interchange  (XMI)  format,  which  is  sup¬ 
ported  by  most  UML  CASE  tools. 

The  verification  process  has  three  phases: 

1.  translate  the  UML  diagrams  into  an  ASM  executable 
specification, 

2.  simulate  the  execution  of  the  generated  specification, 
and 

3.  verify  OCL  constraints  against  the  resulting  execution 
graph. 

The  UML  compiler  translates  UML  diagrams  to  an  ASM 
according  to  a  formally-defined  semantics.  Basic  diagram 
elements,  such  as  classes  and  method  names,  are  mapped 
to  sorts  (data  domains).  More  complex  elements,  such  as 
method  declarations  and  statechart  transitions,  are  trans¬ 
lated  into  enumerated  functions.  The  object  diagram  is 
mapped  to  a  specific  subset  of  these  functions  and  repre¬ 
sents  the  initial  configuration  of  the  UML  diagrams. 

The  ASM  interpreter  simulates  the  execution  of  the  ASM 
specification.  From  an  initial  configuration,  successor  con¬ 
figurations  are  computed  by  evaluating  an  ASM  program 
capturing  the  dynamic  behavior  of  the  UML  diagrams. 

The  model-checker  verifies  the  OCL  constraints  by  trans¬ 
lating  them  into  a  set  of  properties  and  applying  a  verifi¬ 
cation  algorithm  [4].  The  result  is  transmitted  back  to  the 
graphical  user  interface  through  a  set  of  diagnostic  files. 

SoCLe  includes  a  graphical  user  interface  embedded  into 
argoUML,  a  customizable  open-source  UML  CASE  tool3.  It 
allows  the  designer  to  visualize  verification  results  and  to 
inspect  the  diagrams’  execution  graph. 

2For  the  sake  of  brevity  and  to  respect  the  scope  of  this  paper,  no  tech¬ 
nical  details  are  given  about  the  ASM  formalism  and  model-checking  tech¬ 
niques. 

'  lit  tp://argon  ml.tigris.org. 
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Figure  1.  SocLe  Architecture 


4.  Caveat- Separation  System:  Simplified  Case 
Study  Specifications 

The  main  objective  of  the  case  study  is  relatively  sim¬ 
ple:  design  and  verify  a  simplified  caveat-separation  system 
based  on  the  following  specifications. 

4.1.  Users 

Of  course,  a  caveat-separation  system  implies  the  man¬ 
agement  of  users.  In  this  system,  users  have  the  following 
attributes: 

•  A  security  clearance:  “Enhanced”,  “Confidential”, 
“Secret”,  or  "Top  Secret”. 

•  A  country  of  origin.  For  example:  “Canada”,  “US”, 
“UK”,  “Germany”,  or  “Egypt”. 

•  A  military  rank:  “General”,  “Officer”,  or  “Civilian”. 

Except  for  the  country  of  origin,  these  attributes  can  be 
modified  in  time.  For  instance,  one  particular  user  can  be 
upgraded  from  “civilian”  to  “officer”  or  from  “secret”  to 
“top  secret”.  It  is  infrequent  for  a  military  rank  to  be  down¬ 
graded  but  the  system  should  handle  this  situation  for  the 
sake  of  completeness.  For  example,  a  retired  military  offi¬ 
cer  working  as  a  contractor  could  be  classified  civilian  for 
caveat-evaluation  purposes. 


4.2.  Documents 

In  this  caveat-separation  system,  users  want  to  access 
documents.  Documents  have  the  following  attributes: 

•  A  classification  level:  “Unclassified”,  “Confidential”, 
“Secret”,  or  “Top  Secret”. 

•  A  caveat.  For  example:  “CEO”,  “CANUS”, 
“CANUSUK”,  “NATO”,  “UN  Coalition”,  or  “USUK”. 

•  An  affiliation  with  a  project.  For  example:  “Project 
A”,  “Project  B”,  or  “Project  C”. 

Here,  all  attributes  can  be  modified  during  the  lifespan  of 
a  document,  even  though  certain  modifications  are  unlikely 
to  happen. 

4.3.  Access  Control  Tables 

There  are  three  access  control  tables  that  dictate  who  can 
access  which  documents:  the  classification  table  (Table  1), 
the  caveat  table  (Table  2),  and  the  need-to-know  table  (Table 
3).  They  are  all  presented  in  the  following  subsections. 

4.3.1  Classification  Table 

Table  1  presents  the  access  relation  between  the  security 
clearance  of  users  and  the  classification  level  of  documents. 
Of  course,  the  higher  the  classification  level  of  a  document, 
the  higher  the  security  clearance  required  to  access  it.  This 


Classification  level  /  Security  clearance 

Enhanced 

Confidential 

Secret 

Top  Secret 

Unclassified 

Granted 

Granted 

Granted 

Granted 

Confidential 

Denied 

Granted 

Granted 

Granted 

Secret 

Denied 

Denied 

Granted 

Granted 

Top  Secret 

Denied 

Denied 

Denied 

Granted 

Table  1.  Classification  Table 


table  is  not  simply  an  example.  It  is  fixed  once  and  for  all 
in  the  caveat-separation  system. 

4.3.2  Caveat  Table 

In  Table  2,  the  caveat  of  the  document  dictates  acceptable 
countries  of  origin  for  the  user  who  wants  to  access  it.  This 
table  is  simply  an  example.  Of  course,  many  other  caveats 
and  countries  exist.  However,  for  the  purpose  of  the  current 
caveat-separation  system,  it  can  be  considered  to  be  fixed. 

4.3.3  Need-to-Know  Table 

Table  3  determines  who,  in  terms  of  countries  of  origin  and 
military  ranks,  has  the  “need-to-know”  in  order  to  access 
the  documents  of  a  particular  project.  A  user  must  not  only 
have  the  proper  security  clearance  and  country  of  origin  to 
be  able  to  access  a  document  but  must  also  have  what  is 
called  the  “need-to-know”.  In  this  caveat-separation  sys¬ 
tem,  it  is  assumed  that  this  “need-to-know”  is  attributed  on 
a  per-project  basis  and  is  related  to  a  user’s  country  of  ori¬ 
gin  and  military  rank.  This  table  is  simply  an  example  and 
should  not  be  considered  fixed  once  and  for  all  in  the  caveat- 
separation  system.  Indeed,  new  projects  could  be  created, 
old  projects  could  be  terminated,  and  entries  could  be  mod¬ 
ified  or  deleted  in  time. 

4.4.  Property  to  Verify 

Finally,  the  following  property  must  be  verified  to  be 
valid  in  the  design  of  the  current  caveat-separation  system: 

At  all  times,  a  user  can  access  a  document  if  and 
only  if  the  access  is  granted  with  respect  to  the 
classification,  caveat,  and  need-to-know  tables. 

This  is  particularly  essential  if  the  attributes  and/or  the 
need-to-know  table  are  dynamically  modified. 

5.  Caveat-Separation  System:  UML  Design 

For  any  given  design  in  SOCLe,  the  designer  must  in¬ 
clude  exactly  one  class  diagram,  one  statechart  diagram  for 


each  class  defined  in  the  class  diagram,  and  one  object  dia¬ 
gram.  In  this  section,  these  diagrams  are  illustrated  through 
the  modeling  of  the  case  study. 

5.1.  Class  Diagram 

Figure  2  presents  the  class  diagram  of  the  simplified 
caveat-separation  system  used  as  a  case  study.  Class 
Document  models  a  document  in  the  system  with  its  as¬ 
sociated  security  level,  caveat,  and  project.  Class  User 
models  a  user  who  has  access  to  the  system  with  its  as¬ 
sociated  security  clearance,  country  of  origin,  and  military 
rank  (or  civilian).  Two  roles  are  represented  for  users: 
senders  (class  Sender )  and  receivers  (class  Receiver )  of 
documents.  The  class  Controller  manages  accesses  to  doc¬ 
uments  by  users.  This  class  accesses  the  three  tables  that 
dictate  which  user  can  access  which  document.  The  classes 
TableSecret,  TableCaveat,  and  TableProject  model  the 
classification  table  (Table  1),  the  caveat  table  (Table  2),  and 
the  need-to-know  table  (Table  3),  respectively. 

In  order  to  be  properly  handled  by  the  SOCLe  tool,  the 
information  contained  in  these  three  tables  is  encoded  as 
per  tables  4,  5,  6,  7,  8,  and  9. 


Unclassified 

0 

Confidential 

1 

Secret 

2 

Top  Secret 

3 

Table  4.  Classification  Level  Encoding 


Enhanced 

0 

Confidential 

1 

Secret 

2 

Top  Secret 

3 

Table  5.  Security  Clearance  Encoding 


Caveat  /  Country  of  origin 

Canada 

United  States 

United  Kingdom 

Germany 

Egypt 

CEO 

Granted 

Denied 

Denied 

Denied 

Denied 

CANUS 

Granted 

Granted 

Denied 

Denied 

Denied 

CANUSUK 

Granted 

Granted 

Granted 

Denied 

Denied 

NATO 

Granted 

Granted 

Granted 

Granted 

Denied 

UN  Coalition 

Granted 

Granted 

Granted 

Granted 

Granted 

USUK 

Denied 

Granted 

Granted 

Denied 

Denied 

Table  2.  Caveat  Table 


Project  /  Country  of  origin 

Canada 

United  States 

United  Kingdom 

Germany 

Egypt 

A 

G-O 

G-O-C 

B 

G-O-C 

G-O-C 

C 

G 

G-O 

G-O-C 

G-O-C 

D 

G-O 

G-O-C 

G-O-C 

E 

G-O-C 

G-O-C 

G 

F 

G-O-C 

G-O 

Legend 

G:  General 
O:  Officer 
C:  Civilian 


Table  3.  Need-to-Know  Table 


CEO 

10 

CANUS 

11 

CANUSUK 

12 

NATO 

13 

UN  Coalition 

14 

USUK 

15 

Canada 

100 

United  States 

200 

United  Kingdom 

300 

Germany 

400 

Egypt 

500 

Table  6.  Caveat  Encoding 


Table  7.  Country  of  Origin  Encoding 


5.2.  Statechart  Diagrams 

Statechart  diagrams  are  used  to  define  the  dynamic  be¬ 
havior  of  each  object  in  the  system.  Figures  3  and  4 
show  the  statechart  diagrams  of  the  Sender  and  Controller 
classes,  respectively.  Every  class  must  have  its  statechart  in 
order  for  SOCLe  to  be  able  to  predict  its  dynamic  behavior. 
For  the  sake  of  brevity,  however,  all  the  statecharts  are  not 
presented  in  this  paper. 

Notice  that  the  control  flow  of  a  statechart  is  specified  by 
states  and  transitions.  The  basic  condition  for  a  transition 
to  be  fired  is  that  its  source  state  is  active.  Accordingly,  the 
basic  response  to  firing  a  transition  is  the  activation  of  its 
target  state.  In  the  case  of  composite  states,  the  initial  states 
they  encompass  are  also  activated.  This  basic  statechart  se¬ 


mantics  is  adapted  from  Harel’s  statecharts  [6], 

In  addition,  transitions  are  labeled  with  a  trigger,  a  guard, 
and  a  list  of  actions.  Triggers  refer  to  signals  (atomic 
events),  method  calls,  or  method  returns.  For  example, 
the  list  of  actions  of  a  transition  labeled  with  trigger  inc 
(for  incrementation)  will  execute  that  method’s  instructions. 
Guards  are  boolean  OCL  constraints.  OCL  constraints  are 
presented  in  Section  6.  SOCLe  supports  the  following 
actions:  method  call/return,  field  assignment,  object  cre¬ 
ation/deletion,  and  signal  emission. 

5.3.  Object  Diagram 

The  object  diagram  is  used  to  define  the  initial  state  of 
all  objects  in  the  system.  In  other  words,  it  gives  the  ini¬ 
tial  configuration  of  the  system.  Figure  5  shows  a  possible 


Figure  2.  uml  Class  Diagram  of  the  Caveat-Separation  System 


A 

1 

B 

2 

C 

3 

D 

4 

E 

5 

F 

6 

Table  8.  Project  Encoding 


General 

99 

Officer 

88 

Civilian 

77 

Table  9.  Rank  Encoding 


object  diagram  for  the  caveat-separation  system. 

This  diagram  models  a  system  composed  of  a  user  who 
can  send  a  document  to  another  user  via  a  controller.  Using 
Tables  1,  2,  and  3,  the  latter  determines  if  the  receiver  can 
have  access  to  the  document. 


6.  OCL  Constraints 

The  syntax  of  an  OCL  constraint  c  is  defined  as  follows: 

c  ::=  v|x|Ac|ciAc2|c./|ci.iterate(xi;  X2  =  C2 1 C3 ) 

It  includes  a  significant  fragment  of  OCL  constraints  as 
defined  in  [9].  Symbols  v  and  x  denote  values  and  vari¬ 
ables,  respectively.  Values  include  booleans,  integers,  ob¬ 
ject  names,  and  lists.  Construct  Ac  (C1AC2)  stands  for  the 
application  of  any  of  the  usual  unary  (binary)  operators  on 
booleans,  integers,  and  lists.  Construct  c.f  returns  the  value 
that  field  /  takes  in  the  object  c.  The  semantics  of  these 
constructs  is  formally  defined  as  follows: 


Hp 

=  V 

1*1  p 

=  p(x) 

[Ac]p 

a 

< 

11 

[ciAc2]p 

=  [ci]pA[c2]p 

[ci.fh 

=  heapdajp,  f) 

The  application  p(x)  retrieves  the  value  of  variable  x  in 
the  variable  environment  p.  The  application  heap{\c.\\p,  /) 


Figure  3.  uml  Statechart  Diagram  of  the 
Sender  Class 
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fetches  the  value  of  field  /  according  to  the  ASM  function 
heap ,  defined  by  the  UML  compiler. 

The  iterate  construct  is  OCL’s  main  collection  opera¬ 
tor.  Informally,  it  iterates  variable  X\  through  the  values  of 
the  collection  denoted  by  ci,  stores  the  successive  values  of 
C3  in  variable  X2  (which  first  evaluates  to  C2),  and  returns 
the  final  value  of  x^-  The  formal  semantics  of  this  con¬ 
struct  is  simply  too  complex  for  the  scope  of  this  paper.  It 
is,  however,  quite  expressive  and  this  is  why  it  is  used  to  en¬ 
code  additional  collection  operators,  that  are  supported  by 
SoCLe.  Figure  6  illustrates  some  of  them. 


Figure  4.  uml  Statechart  Diagram  of  the 

Controller  Class 


size 

forall(ui|c) 

exists(t;i|c) 

unique(ui|c) 
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iterate^;  t>2  =  true|  i>2&c) 
iterate(ui;  t>2  =  false|u2|c) 
iterate^;  v%  =  falsejt^l  |c) 


Figure  6.  Additional  Collection  Operators 


7.  Caveat-Separation  System:  An  OCL  Con¬ 
straint 

It  is  possible  to  give  OCL  constraints  for  each  statechart 
of  the  system  in  order  to  validate  each  module  separately 
but  it  is  even  more  interesting  to  define  global  OCL  con¬ 
straints  that  validate  the  entire  system  as  a  whole.  The 
OCL  constraint  defined  in  Figure  7  is  a  good  example  of 
such  constraint.  It  ensures  that  the  behavior  of  the  con¬ 
troller  is  correct.  Since  the  security  of  the  whole  sys¬ 
tem  depends  on  the  controller,  its  behavior  must  be  val¬ 
idated.  The  constraint  verifies  the  three  conditions  that 
must  be  valid  prior  to  the  execution  of  the  operation 
access(u  :  User,d  :  Document ): 

1 .  the  security  clearance  of  the  user  is  higher  or  equal  to 
the  classification  level  of  the  document  (1), 

2.  the  nationality  of  the  user  is  compatible  with  the  caveat 
of  the  document  (2),  and 


3.  the  military  rank  of  the  user  is  compatible  with  the  doc¬ 
ument  project  (3)  (modeling  the  need-to-know). 

As  shown  in  Figures  8,  9,  10,  11,  12,  and  13,  SoCLe 
can  automatically  verify  this  constraint  for  the  entire  sys¬ 
tem.  This  ensures  the  security  of  its  design. 

8.  Conclusion  and  Future  Work 

This  paper  has  presented  a  tool  that  integrates  the  design 
of  software  applications  and  their  security  by  using  OCL 
constraints  on  UML  diagrams  combined  with  innovative  au¬ 
tomatic  verification  techniques.  Such  a  tool  is  of  paramount 
importance  for  the  design  of  critical  military  command  and 
control  information  systems  because  these  systems  have  to 
be  not  only  robust  but  also  secure.  Moreover,  the  detection 
and  correction  of  errors  earlier  in  the  development  cycle 
saves  time  and  money.  Finally,  a  case  study  on  a  caveat- 
separation  system  has  been  presented  in  order  to  illustrate 


the  capabilities  of  the  SoCLe  tool. 

A  few  improvements  are  currently  underway.  They  es¬ 
sentially  consist  in  translating  the  UML  diagrams  into  an  in¬ 
termediate  control  flow  language  before  analyzing  their  be¬ 
havior  and  using  a  local  model-checking  algorithm  to  drive 
the  computation  of  a  system’s  execution  graph.  Such  im¬ 
provements  will  facilitate  the  implementation  of  various  sta¬ 
tic  analysis  techniques  such  as  slicing  and  code  generation. 
They  will  also  reduce  memory  requirements  as  some  con¬ 
straints  could  be  falsified/verified  even  tough  the  execution 
graph  is  only  partially  computed. 
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Figure  5.  Possible  uml  Object  Diagram  for  the  Caveat-Separation  System 


context 

:  Controller  ::  access(u  :  User ,  d  :  Document) 

pre 

:  u. clearance  >  d. level 
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Figure  7.  OCL  Constraint  for  Operation  access(u  :  User ,  d  :  Document )  of  the  Controller  Class 


Figure  8.  SocLe  Screenshot:  Class  Diagram 


Figure  9.  SocLe  Screenshot:  Statechart  Diagram  of  the  Controller  Class 


Figure  10.  SocLe  Screenshot:  Object  Diagram 


Figure  11.  SocLe  Screenshot:  Verifying  ocl  Constraint 


Figure  12.  SocLe  Screenshot:  Selecting  a  Node  in  the  Statechart  Diagram  to  Obtain  the  Correspond¬ 
ing  Execution  Path 


Figure  13.  SocLe  Screenshot:  Browsing  the  Execution  Path  in  the  Diagnosis 
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High-Assurance  Software:  A  Question  of 
Correct  Design 


•  Software  abounds  in  mission-critical  systems 

-  Banks,  hospitals,  emergency  services,  public  utilities, 
governments,  military  organizations,  etc. 

•  High  reliability  and  security  requirements 

-  But  very  complex  and  fragile 

•  Three  main  issues: 

-  Design  problems  (system  architecture) 

-  Implementation  problems  (programming  languages 
and  platforms  used) 

-  Malicious  code  (viruses,  trojans,  worms,  backdoors, 
etc.) 

•  Correcting  errors  during  or  after  implementation  is  costly 

-  50  to  100  times  more  expensive  than  at  design-time 

Source:  B.  W.  Boehm  and  P.  Papaccio. 

Understanding  and  controlling  software  costs.  In 
IEEE  Transactions  on  Software  Engineering, 
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Validating  Design:  Our  Key  Approach 


•  Integrate  design  and  system  specification 

•  Use  an  innovative  mix  of  UML  and  OCL 
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UML  and  OCL 


•  UML  is  the  de  facto  standard  software  design 
notation 

-  Used  in  the  industry  and  in  C2IS  and  other 
governmental  critical  systems 

•  OCL  is  a  complementary  constraint  language 

-  Eliminates  ambiguities  in  software  design 

-  Formulates  pre-/post-conditions  and 
invariants 

-  Part  of  UML 


UML:  Unified  Modeling  Language 

OCL :  Obj  ect  Constraint  Language  Defence  R&D  Canada  -  Valcartier  #  4 
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Caveat-Separation  System:  A  Simplified 
Case  Study 


•  Users 

-  Security  clearance:  Enhanced,  Confidential,  Secret, 
or  Top  Secret 

-  Country  of  origin:  Canada,  United  States,  United 
Kingdom,  Germany,  Egypt,  etc. 

-  Military  rank:  General,  Officer,  or  Civilian 

•  Documents 

-  Classification  level:  Unclassified,  Confidential, 
Secret,  or  Top  Secret 

-  Caveat:  CEO,  CANUS,  CANUSUK,  NATO,  UN 
Coalition,  USUK,  etc. 

-  Affiliation  with  a  project:  A,  B,  C,  etc. 
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Caveat-Separation  System:  A  Simplified 
Case  Study 


•  Access  Control  Tables 

-  Classification  table:  access  relation  between  the 
security  clearance  of  users  and  the  classification  level 
of  documents 

-  Caveat  table:  caveats  dictate  acceptable  countries  of 
origin  for  users  who  want  to  access  documents 

-  Need-to-Know  table:  determines  the  need-to-know, 
in  terms  of  countries  of  origin  and  military  ranks,  that 
is  necessary  to  access  the  documents  of  a  particular 
project 

•  System  property 

-  At  all  times,  a  user  can  access  a  document  if  and  only 
if  the  access  is  granted  with  respect  to  the  three  access 
control  tables. 
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SOCLe  Prototype 


•  Design  the  system  in  the  usual  way 

-  Class  diagrams,  object  diagrams, 
collaboration  diagrams,  statecharts,  etc. 

-  Add  OCL  constraints 


SOCLe  constructs  an  underlying  model 

-  Formally  verified  by  under-the-hood  model¬ 
checking 

-  Transparent  to  the  designer 
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Conclusion 


•  Critical  software  design  should  be  and  can  be  formally 
verified  to  some  extent 

•  Reduces  the  risk  of  design  problems  and  defects  in  the 
implementation 

•  Error  detected 

-  Falsified  property  when  the  access  rules  for 
documents  can  be  updated  while  the  pomt-to-pomt 
transfer  is  still  in  progress. 

•  Reasonably  scalable 

-  But  state  explosion  on  large  systems 

•  Work  in  progress 

-  State  reduction  techniques 

-  On-the-fly  validation 
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Conclusion 


•  Technical  reports 

-  Caveat  Case  Study 

-  An  ASM  Semantics  of  UML  and  OCL 

-  Java  Source  Code  Generation  from  UML 

-  etc. 

•  Quebec  Provincial  FIQ  OCTAS  2005  Winner 

-  Finalist  in  the  Canadian  CIPA  Awards 

•  IBM  Canada  at  Ottawa  is  particularly  interested  in  SOCLe 
technology  transfer 

-  Inline  with  their  current  vision 

-  PolyMTL  is  currently  preparing  a  proposition  for  IBM 
on  how  to  integrate  this  technology  into  their  tools 
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Frederic.Painchaud@drdc-rddc.gc.ca 


http://www.polymtl.ca/crac/socle 


